Resource ReSerVation Protocol (RSVP) is an IP signaling protocol used by applications to signal their quality of service (QoS) requirements. RSVP is designed to support sessions from multiple senders to multiple receivers. When RSVP signaling triggers traffic management, the result is dynamic reservation of network resources (for example, bandwidth and buffers) that achieve a desired QoS for packet delivery. RSVP is receiver-oriented, that is, the application that receives the QoS flow is responsible for initiating the RSVP signaling that reserves network resources. Thus, QoS in RSVP is accomplished by establishing reservations along each hop in the path from the receiver to the sender. A reservation consists of a set of parameter values that determine the QoS for a traffic flow. The sender and receiver, which are host applications that are enabled for RSVP, create the reservation by sending RSVP messages to one another. An IBM enhancement allows some non-RSVP enabled applications to have their first-hop router perform RSVP signaling on their behalf. RSVP runs on IPv4 in the IBM routers and supports both unicast and multicast IP traffic. A full description of RSVP is found in RFC 2205.
For each IP traffic flow for which a reservation has been established, RSVP, as implemented on the 2216, provides Controlled Load quality of service. Controlled Load QoS is defined in the Integrated Services model of the Internet Engineering Task Force (IETF) (RFC 2211). Even when the network becomes congested, Controlled Load QoS continues to provide the level of service that the traffic flow receives when the network is not congested.
This chapter includes the following sections:
Figure 38 shows the sequence of messages that RSVP uses to establish a reservation that provides QoS to a particular traffic flow. For this example, assume that Best Effort IP traffic flows are already established among the routers.
Figure 38. RSVP Reservations-All Routers Support RSVP
The establishment of an RSVP reservation begins when an RSVP-enabled sender sends PATH messages towards the receivers of the data traffic flow. The PATH message contains traffic information that describes the flow. When routers receive a PATH message (by looking at the ALERT Option field of the IP header), they establish and maintain a soft state for that PATH message. An RSVP router will also mark the PATH message that it sends on toward the destination with its own IP address, called the previous-hop or p-hop. An RSVP-enabled receiver can respond to one of the PATH messages by sending back a RESV message. The RESV message requests network resources such as bandwidth to be reserved along each link in the path. The RESV message is sent along the reverse path that the PATH message traversed. The RESV message is received by the first router (Router R3) on the reverse path. This router attempts to reserve resources on the outbound interface, that is, on the link between R3 and the receiver host. If the requested resources are available, then they are reserved for this flow, and the amount of available resources is decreased by the corresponding amount. If the requested resources are not available, then the reservation fails at that node and a RESVERR message may flow back to the receiver host. For now, assume that the reservation is successful.
Router R3 sends the RESV message on to the next router (R2) on the path back toward the sender. R2 sets up a reservation on the link between itself and R3 and sends the RESV message on to R1. R1 sets up a reservation on the link between itself and R2 and sends the RESV message to the sender host. In this example, the sender host supports RSVP. It sets up a reservation on the link between itself and R1. A path of reserved links now forms a reservation that has been established from the sender to the receiver.
Now consider a network where not all nodes support RSVP, as shown in Figure 39.
Figure 39. RSVP Reservations-Not All Routers Support RSVP
In particular, suppose that R2 does not support RSVP. When R2 receives the PATH message, it treats it as an ordinary packet and forwards it toward R3. R2 does not change the p-hop contained in the PATH message
As before, when the PATH message reaches the receiver host, it starts the reservation process by sending a RESV message to R3. The previous-hop that R3 sees on the RESV message is the address of R1 because R2 did not supply its previous hop in the PATH message. R3 sends the RESV message to R1 and makes the reservation on the link between itself and the receiver host. When R1 receives the RESV message from R3, it makes the reservation from itself to R3. Now, reservations (in the direction of the sender) exist in the sender, R1, and R3. Packets will pass through R2 as ordinary best effort packets. In this way, RSVP can be used in a network in which not all routers support RSVP.
Virtual Circuit Resource Manager (VCRM) is a feature that is enabled whenever RSVP is enabled. Based upon the reservation request from RSVP, VCRM creates the connection for the data flow over the physical interface. To do this, VCRM must first determine whether enough bandwidth exists to accommodate the reservation.
| Note: | If you are using WAN interfaces such as frame relay or X.25, you need to set the line speed so that VCRM knows how much bandwidth is available. The procedure for setting the line speed is described in the frame relay and X.25 interface configuration chapters of the Nways Multiprotocol Access Services Software User's Guide . |
If an underlying link in the network supports QoS traffic, such as ATM support of QoS SVCs, VCRM takes advantage of this link capability to establish an ATM SVC to be used by the data traffic for this flow. When the underlying link is not QoS-capable, traffic scheduling and buffering between the network and data link layers aggregate the QoS flows and differentiate them from the best-effort traffic.
If an underlying link is a DiffServ-enabled WAN link, VCRM will request DiffServ to allocate the link resource for the DOS flows, and add the DiffServ TOS marking(s) as traffic flows through the device.
For more information about VCRM, see "Configuring and Monitoring VCRM" in Using and Configuring Features.
A router's path and reserve soft state defines the existence of an RSVP reservation and that the traffic flow is being transmitted according to that reservation. An RSVP session consists of all the traffic flows from one or more senders that are being routed over reserved paths to the same IP session address, which can be either a unique or a multicast IP address. For example, in Figure 41 the session includes the traffic flows from sender S1 to the receiver Rec 1 as well as the traffic flows from sender S2 to the receiver Rec 1. This session is identified by the IP address of the receiver Rec 1.
The senders and receivers maintain the existence of each path and reservation in the session by sending refresh messages that reaffirm the existence of the reserved traffic flow. These refresh messages are just copies of the PATH and RESV messages. Configurable timers will time out and cause the nodes maintaining soft state to tear down the reservation if the node does not receive a refresh message within a certain amount of time.
There are two types of teardown messages - RSVTEAR and PATHTEAR. The RSVTEAR message, which is sent by the receiver, tears down the reservation but not the traffic flow, which continues with best-effort service. The PATHTEAR message tears down the path from the sender to the session address. PATHTEAR tears down both the reservation and the path soft state. Best effort traffic can still flow.
Figure 38 shows the establishment of one RSVP reservation, which reserves links for a stream of traffic from one particular sender to one particular receiver. If multiple senders send to the same receiver, multiple IP traffic flows will exist - one from each sender to the receiver. In this situation, the different senders can share reservations over some of the links to the receiver or not, depending upon the selected reservation style.
Figure 40 shows two senders S1 and S2 for which the receiver has requested the fixed-filter (FF) reservation style. In this reservation style, each sender is provided with its own individual reservation. Host S3 is not participating in RSVP, but is receiving Best Effort traffic.
Figure 40. Fixed-Filter Reservation Style
In the shared-explicit (SE) reservation style, the senders identified as members of a particular group can share some of the reserved links. The senders within a group are defined by the receiver according to information that the senders send in the PATH message, such as the senders' IP addresses. In Figure 41, sender S1 and sender S2 have been included in the RSVP session that is identified by the destination address of receiver Rec 1. The senders in the group share the reservation as soon as the senders' paths to the receiver merge. In this case, the common reservation extends from router R1 to the receiver.
Figure 41. Shared-Explicit Reservation Style
In the third reservation style, wildcard-filter (WF), all senders that send PATH messages to the session address share the same reservation, as illustrated in Figure 42.
Figure 42. Wildcard-Filter Reservation Style
One-Path With Advertising (OPWA) is an optional feature of RSVP. It allows the receiver to obtain a record of the QoS values, such as bandwidth, that are available from each link along the reservation path. For example, if Routers R1 and R3 that are shown in Figure 38 are configured for OPWA, they will be told about the characteristics of each link. This information allows them to adjust the information in the PATH message according to the capacity of the link with the least resources.
For example, in the context of Figure 38, suppose that a sender starts sending PATH messages toward a receiver with an average rate of 1 Mbps and a peak rate of 10 Mbps. Further suppose that the link between R2 and R3 is a PPP link with a line rate of 2 Mbps. OPWA in R2 will alter the peak rate in the PATH message to be decreased to 2 Mbps, since there is no reason for any nodes downstream to reserve for a peak rate higher than 2 Mbps.
The link types that RSVP supports include:
| Note: | For shared media networks such as LANs, other methods, such as traffic engineering, are needed to coordinate the sharing of LAN bandwidth. RSVP controls the bandwidth usage of one particular router, but does not coordinate the usage of the LAN bandwidth by multiple routers and hosts. |
Notes:
As guidance for the configuration of RSVP, a sample of the talk 6 command line interface configuration is included. See Configuring and Monitoring RSVP for descriptions of the RSVP commands and parameters. The following steps describe a sample configuration of RSVP:
Example:
Config> protocol rsvp
Resource ReSerVation Protocol config console
RSVP Config> enable rsvp
RSVP Config> enable interface
Interface [0]?
Creating RSVP i/f record...
Set Link Reservable Bandwidth (bits) [0]? 5000000
Interface enabled.
To take effect immediately, use talk-5 RSVP's 'reset interface'
RSVP Config> enable interface
Interface [0]? 1
Creating RSVP i/f record...
Set Link Reservable Bandwidth (bits) [0]? 1024000
Interface enabled.
To take effect immediately, use talk-5 RSVP's 'reset interface'
RSVP Config>enable opwa
Interface [0]?
Controlled Load installed on interface 0
take effect immediately?(Yes or [No]): y
RSVP Config>enable opwa
Interface [0]? 1
Controlled Load installed on interface 1
take effect immediately?(Yes or [No]): y
Interface enabled.
RSVP Config>list interface
RSVP Interfaces:
If IP address RSVP-enabled Encaps. max_res_bw SRAM_rec
0 5.0.31.5 Y IP 5000000 1
1 5.0.31.3 Y IP 1024000 2
RSVP Config>list opwa
OPWA configuration:
Network OPWA CTL-LOAD
0 Y Y
1 Y Y
After you have completed your configuration, you can activate RSVP by using the talk 5 reset rsvp or reset interface commands or by restarting the router.
If you configure RSVP as described in Sample Configuration, RSVP traffic flows and sessions will be established dynamically by RSVP-enabled applications in hosts that are connected to the router. When there is a host application that is not enabled for RSVP and that sends packets to a known IP address and port, a static sender and receiver can be configured to cause the router to generate RSVP signaling for that flow.
First, configure the sender using the add sender command from the RSVP config> prompt.
Config> protocol rsvp Resource ReSerVation Protocol config console RSVP Config> add sender Session> IP Address: [0.0.0.0]? 5.0.31.1 (1) Session> Port Number: [1]? 5004 Session> Protocol Type (UDP/TCP): [UDP]? Sender> IP Address: [0.0.0.0]? 5.0.27.27 (2) Sender> Src Port: [1]? 5005 Tspec> Peak Rate (in byte/sec) [250000]? 25000 Tspec> Average Rate (in byte/sec) [200000]? 20000 Tspec> Burst Size (in bytes) [2000]? Tspec> Max. Pkt Size [1500]? Tspec> Min Pkt Size [53]?
After using the list sender command to check that the correct values have been configured, you can configure a static receiver in a second remote router that will act as a receiver. In the example, the sending router has the IP address 5.0.27.27 and the receiving router has the IP address 5.0.31.1. To configure the static receiver, use the add receiver command.
RSVP Config>add receiver RESV requestor IP Address: [0.0.0.0]? 5.0.31.1 Session> IP Address: [5.0.31.1]? (1) Session> Port Number: [1]? 5004 Session> Protocol Type (UDP/TCP): [UDP]? Style> (WF, FF, SE): [FF]? wf (2) Need confirmation?(Yes or [No]): Service Type: CTL-LOAD Tspec> Peak Rate (in byte/sec) [250000]? 5000 Tspec> Average Rate (in byte/sec) [200000]? 20000 Tspec> Burst Size (in bytes) [2000]? Tspec> Max. Pkt Size [1500]? Tspec> Min Pkt Size [53]?